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FIELD OF THE INVENTION 

The present invention relates to service request handling in 
IMC (IP Multimedia Core) . In particular, the invention relates 
to redirecting a service request for a served user in IMC. ; 

BACKGROUND OF THE INVENTION 

There are many applications of the Internet that require the 
creation and management of a session, where a session is 
considered an exchange of data between an association of 
participants. The implementation of these applications is 
complicated by the practices of participants : users may move 
between endpoints, they may be addressable by multiple names, 
and they may communicate in several different media - 
sometimes simultaneously. Numerous protocols have been 
authored that carry various forms of real-time multimedia 
session data such as voice, video, or text messages. The 
Session Initiation Protocol (SIP) works in concert with these 
protocols by enabling Internet endpoints (called user agents) : 
to discover one another and to agree on a characterization of ; 
a session they would like to share. For locating prospective 
session participants, and for other functions, SIP enables the 
creation of an infrastructure of network hosts (called proxy 
servers) to which user agents can send registrations, 
invitations to sessions, and other requests. SIP is an agile, :. 
general-purpose tool for creating, modifying, and terminating 
sessions that works independently of underlying transport 
protocols and without dependency on the type of session that 
is being established. 

More details about SIP as defined by the IETF are described in 
RFC 3261. As mentioned above, SIP allows the establishment, 
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handling and release of end-to-end multimedia sessions. There 
are several additions to the SIP protocol, which e.g. allow 
event notification based on SIP, which is the basis for a SIP 
based Presence Service and other services. 

The 3GPP IMS (Third Generation Partnership Project IP 
Multimedia Subsystem) utilizes SIP in order to achieve a wide 
range of functionality within the 3GPP (wireless) network. 

S-CSCFs (Serving Call State Control Functions) in the IMS 
download filter criterions (FCs) from a HSS (Home Subscriber 
System). FCs are evaluated one-by-one, i.e. an incoming 
request is checked by a terminating S-CSCF based on the public 
user identity in the Request-URI (Universal Resource 
Identifier) as to whether the first or initial FC (highest 
priority) matches. If it matches, the S-CSCF sends it to the 
related Application Server (AS) that is indicated by the FC 
and adds a "dialog identifier" in the route header that is 
pointing back to the S-CSCF. 

When the request is sent back from the AS and received again 
at the S-CSCF, the S-CSCF identifies the request by the dialog 
identifier and checks for matching of the next following FCs 
of lower priority, and applies the filter criteria on *the : STP 
method as received from the previously contacted AS. Depending 
on the result of the previous process, the S-CSCF may contact 
one or more application server (s) . 

Due to some special services it might be that the AS e.g. 
redirects the request (e.g. Call Forwarding) . In these cases, 
it might be not desirable for the AS that the S-CSCF performs 
the subsequent FCs. According to the prior art, such behaviour 
of the S-CSCF cannot be affected by the AS. 

Call forwarding as an example of service request redirection 
is one of the most generally used services in 
telecommunication systems. Its utilization significantly 
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impacts session handling in IP Multimedia Core Subsystem, thus 
it should be accurately defined. 

The latest version of 3GPP TS 24.229 Release 5 standard 
(v. 5. 3.0) specifies terminating procedures at S-CSCF generally 
without considering the special effects of executed services* 
Request redirection modifies the Request-URI data of the 
affected session, which requires special processing in S-CSCF 
which cannot be accomplished with the general description of 
the standard. According to the prior art as described in 
chapter 5.4.3.3 "Request terminated at the served user" of 
3GPP TS 24.229, v. 5.3.0, in a situation of request redirection 
such as call forwarding, the execution of the rest of 
procedures will conflict with the purpose of call forwarding. 
According to the general description in point 11 of chapter 
5.4.3.3 "Request terminated at the served user" of 3GPP TS 
24.229, v. 5.3.0, the Request-URI is overwritten, eliminating 
the possibility of call forwarding itself. In other words, 
according to the prior art, a Request-URI is built by the S- 
CSCF with the contents of a saved Contact URL (Universal 
Resource Locator) where the user served by the S-CSCF is 
reachable, which Contact URL is determined from the 
destination .public user identity. 

A specific description of call forwarding is not given so far 
in IP Multimedia Subsystem (IMS) , and call forwarding handling 
in IMS is completely dif f erent f rom that in other existing 
systems. 

SUMMARY OF THE INVENTION 

It is therefore an object of the invention to enable request 
redirection such as call forwarding in IMC. 

According to the invention, this object is achieved by a 
method of processing a service request according to claim l r a 



method of processing a service according to claim 16 and a 
method of handling a service request according to claim 26. 

Moreover, the above object is achieved by a device according 
to claim 12 and a device for processing a service request 
according to claim 27. 

Furthermore, the above object is achieved by a unit according 
to claim 22 and a unit for processing a service according to 
claim 28. 

In addition, the above object is achieved by a computer 
program product according to claim 13 and a computer program 
product according to claim 23. 

The above object is further achieved by an IP multimedia core 
network according to claim 29. 

Further features of the present invention are defined in the 
dependent claims. 

According to the invention, the tasks to be executed by a 
.terminating S-CSGF. in .case of call forwarding are defined. In 
case of call forwarding, the terminating S-CSCF does not 
evaluate further filters but handles the call forwarding. 
Moreover, tasks which may be executed by an application server 
in case of call forwarding are defined. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1A shows a flow diagram illustrating a method of service 
request processing according to the present invention , 

Fig. IB shows a flow diagram illustrating a method of service 
processing according to the present invention. 
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Fig. 2 shows a schematic block diagram illustrating a serving 
device and a processing unit in an IP multimedia core network 
according to the present invention. 

Fig. 3 shows a signaling diagram illustrating service request 
handling according to an embodiment of the present invention. 

Fig. 4 shows a signaling diagram illustrating an example of 
call forwarding handling in S-CSCF according to the embodiment 
of the present invention. 

Fig. 5 shows a signaling diagram illustrating another example 
of call forwarding handling in S-CSCF according to the 
embodiment of the present invention. 

DESCRIPTION OF THE INVENTION 

Figs. 1A and IB and Fig. 2 show the idea of the present 
invention . 

Fig. 1A illustrates a method of processing a service request 
in an IP multimedia core network. In a first step Sll,. a 
service request for a user is -received by a device serving the 
user. For example, this service request has been initiated by 
a first user towards a second user. After having received the 
service request, in step S12 it is forwarded to a unit for 
processing the service. Then, in step S16, a processing result 
is received from the processing unit, and on the basis of the 
received processing result in step S17 it is determined 
whether service request processing for the second user is to 
be stopped. 

Fig. IB shows a method of processing the service according to 
the service request forwarded to the processing unit. In a 
first step S13 a service request initiated by the first user 
towards the second user is received from the device serving 
the second user. In step S14 the service is processed, and in 



step S15, a processing result is returned to the device, on 
the basis of which it can be determined in the device (in step 
S17 in Fig, 1A) whether service request processing for the 
second user is to be stopped. 

Fig. 2 shows an IP multimedia core network (IMC network) 
arranged to perform steps Sll to S17 shown in Figs. 1A and IB. 
In particular, the IMC network comprises a device serving a 
user for processing a service request for the served user and 
a processing unit for processing a service corresponding to 
the service request. 

The serving device comprises a first receiving block for 
receiving a service request for the served user, a forwarding 
block for forwarding the received service request to the 
processing unit for processing the service, a second receiving 
block for receiving a processing result from the processing 
unit, and a determining block for determining, on the basis of 
the received processing result, whether service request 
processing for the served user is to be stopped. 

The processing unit comprises a receiving block for receiving 
the service request from the . serving device, a processing • - - 
block for processing the service, and a returning block for 
returning a processing result to the serving device, on the 
basis of which it can be determined in the device whether 
service request processing for the second user is to be 
stopped. 

According ,to an embodiment of the. invention, -the processing, 
unit may include in the processing result an indication for 
stopping service request processing for the served (second) 
user. Accordingly, the serving device is arranged to check 
whether the processing result received from the processing 
unit includes the indication for stopping service request 
processing for the second user, and in case the indication is 
present, to stop service request processing for the second 
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user. The serving device may also be arranged to check whether 
the indication is valid. 

Moreover, before stopping service request processing for the 
second user, the serving device may perform charging 
processing. 

According to another embodiment of the invention, the received 
service request initiated by the first user may include a 
destination identifier of the second user, and -upon service 
processing, the processing unit may determine that the service 
request is to be forwarded to a third user, replace the 
destination identifier of the second user by a destination 
identifier of the third user, and return the processing result 
with the destination identifier of the third user to the 
serving device. The serving device may compare the destination 
identifiers of the service request forwarded to the processing 
unit and the processing result received from the processing 
unit, and in case it is detected that the compared identifiers 
are different from each other , service request processing for 
the second user is stopped. In addition the serving device may 
determine, on the basis of the received processing result, 
whether the service request is to be forwarded to a third 
user, and may forward the service request to the third user- on 
the basis of the destination identifier included in the 
processing result. 

The service request of the first user received by the serving 
device for the second user may include an originating 
identifier of the first user, and the processing unit may 
include an originating identifier of the second user in, the 
processing result when it determines during processing the 
service that the service request is to be redirected from the 
second user to a third user. Then, in the forwarding 
procedure, the serving device may detect that the originating 
identifier included in the processing result is the ' 
originating identifier of the second user, and may forward the 



service request on the basis of the originating identifier 
included in the processing result . However, in case the 
originating identifier included in the processing result is 
not the originating identifier of the second user, the serving 
device may include the originating identifier of the second 
user in the service request to be forwarded. Alternatively, in 
the forwarding procedure, the serving device may always use 
the originating identifier included in the processing result. 

According to an embodiment of the invention, the originating 
identifier of the first user is replaced by the originating 
identifier of the second user. Alternatively, the originating 
identifier of the second user is added to the originating 
identifier of the first user. 

In the following, an embodiment of the invention will be 
described with reference to Figs. 3 to 5. 

Fig. 3 shows a signaling diagram in which a user A (first 
user) sends an initial service request towards a user B 
(second user) . The seirvice request 1 is received by a device in 
the IMC serving user B (serving device) , e.g. an S-CSCF 
(Serving ' Call- State Control Function) . ' The - ' S-CSCF forwards the 
initial service request to a corresponding application server 
AS (processing unit) for the user B at which the service 
request is processed. After that, the AS returns a processing 
result to the S-CSCF. In so far, the process corresponds to 
3GPP TS 24.229 version 5.3.0 release 5, chapter 5.4.3.3 
"Requests terminated at the served user". 

According to the present invention, in processing the 
terminating services of a- served subscriber or user in S-CSCF, 
after each service execution it should be checked whether, the 
service included a process because of which the S-CSCF should 
not perform the subsequent filter criteria. For example, in 
case of service redirection such as call forwarding further 
terminating services of the called party should not be 



executed, i.e., the check for matching of the next following 
filter criteria of lower priority should be stopped. 

As shown in Fig. 3, the S-CSGF of the user B detects from the 
processing result received from the AS that the terminating 
processing for the user B is to be stopped. Before stopping 
the terminating processing, the S-CSCF may perform charging 
related functions as described in points 5 to 7 of chapter 
6.4.3.3 "Request terminated at the served user" of 3GPP TS 
24.229 v.5.3.0 release 5. 

Further to. the detection that the terminating processing is to 
be stopped, according to the invention it may be detected by 
the S-CSCF that the service request has to be forwarded to 
another user C. After such detection, the S-CSCF may handle 
this request redirection by performing charging related tasks 
as mentioned above and switching to originating mode, and 
finally forward the initial service request towards the user G 
as shown in Fig. 3. 

Fig. 4 shows an example of the embodiment of Fig. 3. According 
to Fig. 4, the initial request sent towards the B S-CSCF 
includes an R-URI (Request-Universal Resource Identifier) : • 
(destination identifier) of user B. The B S-CSCF forwards the 
request to the AS of user B. In processing the service, the B 
AS may detect a redirection of the service request to user C, 
for example. Since in this case the B S-CSCF should not 
perform subsequent filter criteria, the B AS may set an 
indication that the B S-CSCF should not evaluate further 
filter criteria. 

The AS may set this indication as part of e.g. the Request-URI 
of the request that is sent back to the S-CSCF. This may be . a 
tag in the Request-URI, e.g.: 

sip : Georg . Mayer @miesbach . de ; FC=off 



wherein "sip:Georg. Mayer@miesbach.de" is the R-URI of user C. 

This indication may also be set in another way (e.g. extra 
header, parameter of another header, etc.) 

The S-CSCF should then check if the indication is allowed to 
be set by the AS from which it received the request back. If 
it is allowed to set it, the S-CSCF should then stop 
evaluating the subsequent FCs and handle the request 
redirection immediately (or at least immediately after having 
performed charging operations as mentioned above) . In other 
words, when the B S-CSCF detects the tag "FC=off" in the 
processing result returned from the B AS, it stops the 
terminating processing for the user B and switches to the 
originating role e.g. for handling a call forwarding towards 
the Request-URI indicated in the returned processing result. 

Fig. 5 shows a further example of the embodiment of Fig. 3. 
According to Fig. 5, the initial request sent towards the B S- 
CSCF includes an R-URI (Request-Universal Resource Identifier) 
(destination identifier) of user B and a P-A-ID ( P-Asserted 
Identity) header" (origihatirig identifier user A. ' WB'S- 

CSCF forwards the request to the AS of user B. The result of 
processing the service may be a redirection of the service 
request to user C. In order to detect request redirection, the 
Request-URI sent to the AS and the Request-URI received from 
the AS are always compared by the S-CSCF. As shown in Fig. 5, 
the R-URI has changed from B to C, so that the S-CSCF detects 
that the executed request included a request redirection, such 
as call forwarding. 

In call forwarding case the P-Asserted ID header should be 
modified so that the user C is enabled to notice that the 
request or call from user A is coming through user B. For 
example, if user C has a call barring for user A and user A 
calls user B who has call forwarding to user C, then from user 
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B*s point of view the forwarding will fail. According to the 
invention, the modification of the P-Asserted ID header may be 
done either by the AS implementing the call forwarding service 
or the terminating S-CSCF that detects call forwarding (in 
case the AS did not modify the header). According to Fig. 5, 
the B AS has already modified the P-A-ID from A to B. The 
modification is either the replacement of the P- Asserted ID 
header with the served user's IMPU (IP Multimedia Public User 
Identity) (it can be another IMPU of the served user as well) 
as shown in Fig. 5, or the insertion of the served user's IMPU 
(again, it can be another IMPU of the served user as well) to 
the beginning of the original P-Asserted ID header, i.e. ' P-A- 
ID=B,A' . As shown in Fig. 5, the call is then forwarded with 
P-A-ID = B. 

After the detection of call forwarding in the B S-CSCF, the B 
S-CSCF may carry out the tasks related to charging as it is 
described in points 5, 6, arid 7 of chapter 5.4.3.3 "Request 
terminated at the served user" of 3GPP TS 24.229 v. 5. 3.0 
release 5. If user B has set call forwarding, then user B 
should pay for the forwarded part of the call from B to C. 

Upon completing charging related functionality the terminating 
S-CSCF changes the role from terminating S-CSCF to originating 
S-CSCF, and starts to operate as it is described in chapter 
5.4.3.2 "Request initiated by the served user" of 3GPP TS 
24.229 v.5.3.0 release 5, wherein the served user in this 
originating S-CSCF is the forwarding IMPU stored in P-Asserted 
ID header, i.e. user B. In other words, the B S-CSCF switches 
to originating role and forwards the initial service request 
towards user C in accordance with 3GPP TS 24.229 version 5.3.0 
release 5, chapter 5.4.3.2 "Request initiated by the served 
user" . 

The B S-CSCF should ensure that all the restrictions/settings 
defined for the calls originated by B are fulfilled. 
Therefore, according to the present invention, the originating 



services of the user B are executed. Not executing originating 
services in case of call forwarding, for example, would enable 
subscribers to call barred numbers by setting call forwarding 
to such numbers and calling themselves. 

It is to be noted that the charging tasks shown as block 5 in 
Fig. 5 may also be performed in the embodiment shown in Fig. 4 
after the detection that terminating processing for B is to be 
stopped and before actually stopping terminating processing 
for B. Moreover, the P-A-ID modification can also be applied 
to the embodiment shown in Fig. 4. 

Moreover, it is to be noted that the above examples can be 
combined in different manners. For example: 

With respect to R-URI change: 

a. B AS just changes the R-URI, and there is no special 
indication in the processing result. 

b. B AS indicates the change of R-URI in the processing 
result. 

For changing P-A-ID there are. two places for options: 
The place of change: 

0. No change (this is a possible option too, although this way 
C will not know that B is involved) . 

1 . Done in B AS . 

2. Done (at some point) in B S-CSCF after the redirection has 
been detected. 

The way of change: 
X. Replace A with B. 
Y. Replace A with B, A . 

Then, possible combinations are 0, , IX, 1Y, 2X, and 2Y. 
Taking into account also the R-URI change, possible 
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combinations are aO, bO, alX, blX, alY, blY, a2X, b2X, a2Y , 
and b2Y. * 

It is to be understood that the above description is 
illustrative of the invention and is not to be construed as 
limiting the invention. Various modifications and applications 
may occur to those skilled in the art without departing from 
the true spirit and scope of the invention as defined by the 
appended claims. 
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CLAIMS : 

1. A method of processing a service request in an IP 
multimedia core network, comprising the steps of: 

receiving a service request initiated by a first user, for a 
second user; 

forwarding the received service request to a unit for 

processing the service; 

receiving a processing result from the processing unit; and 
determining, on the basis of the received processing result, 

whether service request processing for the second user is to 

be stopped. 

2. The method according to claim 1, the determining step 
comprising the step of: t , 

checking whether the processing result received from the 
processing unit includes an indication for stopping service { 
request processing for the second user, 

wherein in case the indication is present, service request 
processing for the second user is stopped. 

3. The method according to claim 2, further comprising the 

step of : - ■■ ■- - ;-■ - ••. •• •• • ; ' ~ 

in case the indication is present, checking whether the 
indication is valid. i*. 

4. The method according to any one of claims 1 to 3, further 
comprising the step of: 

before stopping service request processing for the second 
user, performing charging processing. 

5. The method according to any one of claims 1 to 4, wherein 
the service request forwarded to the processing unit and the 
processing result received from the processing unit each 
include a destination identifier, the determining step 
comprising the step of: 



comparing the destination identifiers of the service 
request forwarded to the processing unit and the processing 
result received from the processing unit, 

wherein in case it is detected that the compared 
identifiers are different from each other, service request 
processing for the second user is stopped. 

6- The method according to any one of claims 1 to 5 f further 
comprising the step of: 

determining, on the basis of the received processing result, 
whether the service request is to be forwarded to a third 
user. 

7. The method according to claim 6, wherein the service 
request forwarded to the processing unit and the processing 
result received from the processing unit each include a 
destination identifier, the determining step comprising the 
step of: : 

comparing the destination identifiers of the service 
request forwarded to the processing unit and the processing 
result received from the processing unit, * 

wherein in case it is detected that the compared 
Identifiers are different from each other, ' r 

switching to originating mode and forwarding the service 
request on the basis of the destination identifier included in 
the processing result. 

8. The method according to claim 6 or 7, wherein the service . 
request forwarded to the processing unit and the received 
processing result each include an originating identifier, the 
method comprising the step of: 

detecting whether the originating identifier included in 
the processing result is the originating identifier of the 
second user; and ; 

in case the originating identifier included in the 
processing result is the originating identifier of the second 
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user, forwarding the service request on the basis of the 
originating identifier included in the processing result. 

9* The method according to claim 8, wherein in case the 
originating identifier included in the processing result is 
not the originating identifier of the second user, the 
originating identifier of the second user is included in the 
service request to be forwarded on the basis of the processing 
result . 

10. The method according to claim 8 or 9, wherein the 
originating identifier of the first user is replaced by the 
originating identifier of the second user. 

11. The method according to claim 8 or 9, wherein the 
originating identifier of the second user is added to the 
originating identifier of the first user. 

12. A device for processing a service request in an IP 
multimedia core network, the device being arranged to execute 
the steps of the method according to any one of claims 1 to 
11. 

13. A computer program product, comprising software code 
portions for performing the steps of any one of claims 1 to 11 
when the product is run on a computer. 

14. The computer program product according to claim 13, 
wherein said computer program product comprises a computer- 
readable medium on which said software code portions are ' 
stored. 

15. The computer program product according to claim 13, 
wherein said computer program product is directly loadable 
into the internal memory of the computer. 



16. A method of processing a service in an IP multimedia core 
network, comprising the steps of: 

receiving a service request initiated by a first user, for 
a second user, from a device serving the second user; 
processing the service; and 

returning a processing result to the device, on the basis 
of which it can be determined in the device whether service 
request processing for the second user is to be stopped. 

17. The method according to claim 16, further comprising the 
step of: 

including in the processing result an indication for 
stopping service request processing for the second user. 

18. The method according to claim 16 or 17, wherein the 
received service request includes a destination identifier of 
the second user, the method comprising the further steps of: 

upon service processing, determining that the service 
request is to be forwarded to a third user; 

replacing the destination identifier of the second user by 
a destination identifier of the third user; and 

returning the processing result with the destination 
identifier of the third user. 

19 . The method according to claim 18, wherein the received 
service request includes an originating identifier of the 
first user, the method comprising the further steps of: 

including an originating identifier of the second user in 
the processing result when determining that the service 
request is to be redirected to a third user. 

20. The method according to claim 19, wherein the originating 
identifier of the first user is replaced by the originating 
identifier of the second user. 
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21. The method according to claim 19, wherein the originating 
identifier of the second user is added to the originating 
identifier of the first user. 

22. A unit for processing a service in an IP multimedia core 
network, the device being arranged to execute the steps of the 
method according to any one of claims 16 to 21. 

23. A computer program product, comprising software code 
portions for performing the steps of any one of claims 16 to 
21 when the product is run on a computer. 

24. The computer program product according to claim 23, 
wherein said computer program product comprises a computer- 
readable medium on which said software code portions are 
stored. 

25. The computer program product according to claim 23, 
wherein said computer program product is directly loadable 
into the internal memory of the computer. 

26. A method of handling a service request in an IP mu 1 timed i a 
core network, comprising the steps of: 

receiving a service request initiated by a first user, for a 

second user,, in a device serving the second user; 

forwarding the received service request to a unit for 
processing the service; 

receiving the forwarded service request in the processing 
unit; 

processing the service in the processing unit; 

returning a processing result to the device, on the basis of 
which it can be determined in the device whether service 
request processing for the second user is to be- stopped; 

receiving the processing result by the device from the 
processing unit; and 



determining, on the basis of the received processing result, 
whether service request processing for the second user is to 
be stopped. 



27 . A device for processing a service request in an IP 
multimedia core network, comprising: 

means for receiving a service request initiated by a first 
user, for a second user; 

means for forwarding the received service request to a unit 
for processing the service; 

means for receiving a processing result from the processing 
unit; and 

means for determining, on the basis of the received 
processing result, whether service request processing for the 
second user is to be stopped. 

28. A unit for processing a service in an IP multimedia core 
network, comprising: 

; means for receiving a service request initiated by a first 
user, for a second user, from a device serving the second 
user; 

means for processing the service; and 

means for returning a processing result to the device, on 
the basis of which it can be determined in the device whether 
service request processing for the second user is to be 
stopped. 

29. An IP multimedia core network comprising a device 
according to claim 25 and a unit according to claim 26. 



- 20 

ABSTRACT : 

According to an aspect of the invention a method of processing 
a service request in an IP multimedia core network is 
disclosed. The method comprises the steps of receiving a 
service, request initiated by a first user, for a second user, 
forwarding the received service request to a unit for 
processing the service, receiving a processing result from the 
processing unit, and determining, on the basis of the received 
processing result, whether service request processing for the 
second user is to be stopped. 
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